The refresh application password logic that's built into the request builder macros is also running in WpComApiClient, which should not happen.

Sorry, I was wrong about this in the PR description. At the moment, the refresh application password logic does not run in WpComApiClient. So it's not actually relevant to the crash fixed in this PR.

The the main purpose of fetch_authentication_state is checking if the WpAuthenticationProvider instance is still valid. I don't think WpAuthenticationProvider should do the check, because it has no context of how it's being used.

I feel like it might be more appropriate to move fetch_authentication_state to ApiUrlResolver. Maybe we shouldn't call it "url resolver" anymore. Something like HostingProvider may be more suitable? The "hosting provider" should know how to construct a wp/v2/ URL, and since it may also have its own authentication method, it should also know how to check if a WpAuthenticationProvider value is still valid.

#[uniffi::export(with_foreign)]
pub trait HostingProvider: Send + Sync {
    fn resolve(&self, namespace: String, endpoint_segments: Vec<String>) -> Arc<ParsedUrl>;

    fn authentication_state(&self, request_executor: Arc<dyn RequestExecutor>, auth: Arc<WpAuthenticationProvider>) -> Result<AuthenticationState, WpApiError>;
}